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Foreword 


reves with the most challenging business climate in decades, 
business leaders are demanding effective solutions that can 
help them achieve business results while doing more with less. 
They also recognize that now more than ever, driving business 
efficiency alone is not enough. Successfully navigating today’s 
turbulent economic climate also requires agility. Solutions that 
deliver both cost optimization and business agility will be critical 
to companies looking to: 


Adapt to changing customer buying patterns 
Respond to unforeseen business events 


Drive growth strategies when the inevitable economic 
rebound comes 


Now more than ever, companies will be looking to SOA as a critical 
part of their strategy to navigate the economic storm. With SOA, 
companies can leverage the opportunities of an interconnected, 
instrumented, and intelligent world to drive efficiency and 
position themselves for new opportunities on a smarter planet. 


We now know we can’t simply rely on more resources to do our 
work; instead, we must work smarter: 


We must have the agility to shift business models for leaner 
times. 


1#” We must make our business processes more dynamic to 
capture new insights for effective decisions. 


We must have a smart IT platform to support this new way of 
working. 


In short, we need Smart SOA. 


Each business will leverage SOA and embark on a Smarter Planet 
journey in the context of its industry and unique challenges. That 
is why there is such a strong industry focus in Service Oriented 
Architecture For Dummies, 2nd IBM Limited Edition. In these pages 
you will hear businesses from around the world sharing their 
success stories and ideas on how to reduce costs, speed time to 
market, grow customer loyalty for greater retention, and reach 
customers through new channels to drive growth. 
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With that, it is our pleasure to present this copy of Service 
Oriented Architecture For Dummies, 2nd IBM Limited Edition. 

I think it is a great reflection of SOA best practices for today and 
into the future. 


Sandy Carter 
VP, SOA, BPM, and WebSphere 
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Introduction 


MW- to Service Oriented Architecture For Dummies, 2nd 
IBM Limited Edition. We are very excited by the topic and 
hope our enthusiasm is contagious. We believe service oriented 
architecture (SOA) is the most important technology initiative 
facing businesses today. SOA is game changing, and early SOA 
successes make it clear that SOA is here to stay. This book 
introduces you to the basics of SOA in context with the real life 
experiences of seven companies. Seen through the varied business 
environments depicted in each of the case studies, we hope you will 
recognize that SOA is more than a bunch of new software products 
strung together to allow technology companies to have something 
else to sell. SOA represents a dramatic change in the relationship 
between business and IT. SOA makes technology a true business 
enabler and empowers business and technology leaders alike. 


The software industry has been on a journey toward a service 
oriented approach to software for more than 20 years. Smart 
people have known for a long time that if software can be created 
in such a way that it can be reused, life will be a lot better. If 
software can be designed to reflect the way business operates, 
business and technology can align themselves for success. Finding 
good ways to reuse the years of investment in software means 
money spent wisely. These issues are at the heart of SOA and are 
among the reasons we think this book is so important. 


SOA is not a quick fix, but it is a very rewarding adventure. It’s an 
approach built on industry standards — with large doses of 
forethought and planning. It is indeed a journey. We hope this 
book inspires you and helps you get started. 


About This Book 


We have talked with many companies about the challenges and 
successes of their SOA implementations. Not every company gets 
off to a great start right away. The IT executives we spoke with 
were very candid about both the good choices they made and 
some of the bad ones. That’s why we asked everyone if they had 
learned any lessons they would like to share. Service oriented 
architecture is a big new area and requires that a lot of people 
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familiarize themselves with it in a relatively short period of time. 
Understanding the lessons learned and best practices of other 
companies is one of the best ways we know to get lots of different 
people up to speed on a topic very quickly. That’s why we wrote 
this book. If you would like to get deeper into the business and 
technical details and read up on additional case studies, we think 
you'll love Service Oriented Architecture For Dummies, 2nd edition, 
published by Wiley. 


Foolish Assumptions 


Try as we might to be all things to all people, when it came to 
writing this book, we had to pick who we thought would be most 
interested. Here’s who we think you are: 


 You’re smart. You're intelligent, yet the topic of service 
oriented architecture gives you an uneasy feeling; you can’t 
quite get your head around it, and if pressed for a definition, 
you might try to change the subject. 

You're a businessperson who wants little or nothing to do 
with technology, but you live in the 21st century and find 
that you can’t actually escape it. Everybody around you is 
saying “SOA this” and “SOA that,” so you think you better 
find out what they’re talking about. 

Alternatively, you’re an IT person who knows a heck of a 
lot about technology, but this SOA stuff is new, and 
everybody says it’s something different. Once and for all, 
you want the whole picture. 


Whoever you are, welcome. We’re here to help. 


Icons Used in This Book 


Throughout this book, you'll find a couple little icons beside text: 
D 


We think this a particularly useful point to pay attention to. 


Re 
g 
You may be sorry if this little tidbit slips your mind. 
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Chapter 1 


Getting to Know SOA 


In This Chapter 
Understanding why you should care about SOA 
Defining SOA 
Saving bundles by using what you have 
Using SOA to improve quality of service 
Illustrating the benefits of SOA 
Getting started with SOA 


n these times of economic uncertainty, it has become startlingly 

clear that the viability of a business requires adaptability, 
accountability, and credibility. Businesses of all sizes and in all 
industries rely on technology to become more flexible, to uphold 
government and industry regulations and standards, to anticipate 
and plan for the future, and to make the right decisions at the right 
time. “Why SOA?” you ask. Today, the very survival of a business 
hinges on its ability to adapt its IT to meet ever-changing business 
challenges. SOA helps business and IT to unify goals and bridge 
the gaps between their very separate worlds by establishing a 
common language and creating a more flexible infrastructure to 
support change. 


Service oriented architecture (SOA) is a business approach to 
building IT systems that allows businesses to 


Leverage existing assets 
Create new ones 


Easily enable the inevitable changes required to support the 
business 


With SOA, business and IT have a means to meet each other half- 
way and work together using a business focused approach to 
develop new ways to use technology to grow the firm. SOA helps 
companies to develop tools they need to spot new trends and 
opportunities and see new ideas to fruition. 


These materials are the copyright of Wiley Publishing, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


4 Service Oriented Architecture For Dummies, 2nd IBM Limited Edition 


SOA Means Smarter Business 
and Smarter IT 


SOA can make it easier and faster to build and deploy IT systems 
that directly serve the goals of a business. SOA integrates business 
requirements with an IT framework that simultaneously leverages 
existing systems and enables business change. A SOA enables the 
business to keep its focus on business and allows IT to evolve and 
keep pace in a dynamically changing world. 


We divide the world of SOA into the Business Services layer and 
the Plumbing layer. Imagine a diagram that shows all the software 
that your organization runs. Divide it into the Business Services 
layer and the Plumbing layer. The Business Services layer 
contains your business logic. Your Plumbing deals with your 
computing resources. 


Business managers need not understand the intricacies of the 
Plumbing layer and everything it contains. If you cover up the 
Plumbing layer, you’re left with a diagram that shows all the 
business services that software applications provide, both inside 
your organization and to others that interact (technologically 
speaking) from outside, like your customers, business partners, 
and suppliers. Looking at your organization’s software resources 
in this way, you may be able to think about ways to improve or 
better exploit the software assets you have. 


Likewise, if you cover up all the business functionality in your 
SOA diagram, you are left with a set of plumbing services that 
your IT department is responsible for providing. We know that 
many of your “legacy” applications also have a good deal of 
plumbing in them, and the Plumbing layer doesn’t replace that. 
However, SOA enables an IT department to choose how it will 
evolve toward providing a service oriented architecture — and, in 
time, might obviate a good deal of poor plumbing. 


SOA doesn’t guarantee happier employees and a more efficient 
and highly profitable business. Lots of work has to be done to 
create a well-managed SOA environment. However, movement 
toward SOA is usually a movement toward technical freedom and 
business flexibility and bodes well for the performance and 
profitability of an organization and for the sanity of the people 
managing the business. 
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What Is SOA? 


A service oriented architecture (SOA) is an architecture for 
building business applications as a set of loosely coupled black- 
box components orchestrated to deliver a well-defined level of 
service by linking together business processes. 


Admittedly, this definition doesn’t flow trippingly from the 
tongue. However, from it springs a sustainable, reusable, 
extensible approach to business and technology that is already 
providing huge competitive advantages to organizations around 
the globe. Here’s a little elucidation: 


SOA is for building business applications. Many legitimate 
approaches to software architecture exist, and SOA isn’t 
intended for building every kind of software. It is intended 
explicitly for building business applications. 


SOA is a black-box component architecture. SOA deliberately 
hides complexity wherever possible, and the idea of the black 
box is integral to SOA. The black box enables the reuse of 
existing business applications by adding a fairly simple 
adapter to them, no matter how they were built. 


SOA components are loosely coupled. The term loosely 
coupled refers to how two components interact within a 
SOA. One component passes data to another component 
and makes a request. The second component carries out the 
request and, if necessary, passes data back to the first. The 
emphasis is on simplicity and autonomy. Each component 
offers a small range of simple services to other components. 


A set of loosely coupled components does the same work 
that used to be done inside tightly structured applications, 
but the components can be combined and recombined in 
myriad ways. This makes the overall IT infrastructure much 
more flexible. 


SOA components are orchestrated to link together 
through business processes to deliver a well-defined level 
of service. SOA creates a simple arrangement of components 
that can, collectively, deliver a very complex business service. 
Simultaneously, SOA must provide acceptable service levels. 
To that end, the architecture embodies components that 
ensure a dependable service level. Service level is directly 
tied into the best practices of conducting business — 
commonly referred to as business process management. 
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From our perspective, one of the most important aspects of SOA 
is that it’s a business approach and methodology as much as it is 
a technological approach and methodology. SOA enables businesses 
to make business decisions supported by technology instead of 
making business decisions determined by or constrained by 
technology. And with SOA, the folks in IT finally get to say “yes” 
more often than they say “no.” 


«i? No sizable business can function without IT — it’s as simple as 
that. However, we are advocating a new world order. We advocate 
that business leaders and IT work together to create this new 
world order. Together, business leaders and IT will communicate 
how the automated processes of its business should be facilitated, 
and work together to make it a reality by using SOA. Together, IT 
and business leaders can determine a strategy that both liberates 
business from IT and allows IT to create maintainable, extensible, 
compliant systems to support the initiatives determined by 
business leaders. 


Better Living through Reuse 


One of the biggest deals in the SOA world is that you don’t have to 
throw things away. You take the stuff (software assets) that you 
use every day — well, the best of the stuff you use every day — 
and package it in a way that lets you use it, reuse it, and keep on 


reusing it. 
wore One problem common to many large companies is that they have 
s lots of similar programs — software applications — representing 


commonly used business processes. Every time a department 
wants something slightly different, it has its own version of the 
software built so that across a particular company, you might find 
umpteen versions of more or less the same process — with, of 
course, slight variations. Many IT shops have policies and proce- 
dures designed to prevent this sort of thing, but reality intervenes 
with software packages being bought or user departments insisting 
on having their way. Such duplication becomes a nightmare when 
one company acquires another and finds that they have similar 
(but not identical) applications purporting to do the same thing. 


These slight variations are a major cause of systems becoming 
very complicated and expensive to maintain — even one business 
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policy change might affect lots of different applications. In 
situations like this, it’s very difficult to find every instance in 
every application that needs to be changed. The testing required 
for this type of change takes time away from more innovative 
development work and inhibits businesses from getting to market 
quickly with new products. 


With SOA, these important business processes — such as 
creating an invoice, calculating an interest rate, securing a 
reservation — become business services. Briefly, a business 
service is a sealed container of software code that describes a 
specific business process that can be connected to other 
business processes. You end up with one single business service 
for a given function that gets used everywhere in your 
organization. With SOA, when you need to change a business 
policy, you change it in only one place. And, because the same 
service is used everywhere, you have consistency throughout 
your organization. 


For example, you know that if you decide to create a new line of 
business in your organization, you’re not going to create new 
Accounting, Human Resources, Legal, Cleaning, Training, and 
Travel departments to go along with it. Even if you need to add 
staff, you'll likely use your existing Accounting, HR, Cleaning, 
Training, and Travel departments to service — note the word 
service — this new department. 


The problem is that over time, IT (no, not those nice folks in the 

IT department today, but over time) ends up embedding redundant 
functions in programs everywhere in the organization. That 
redundancy — just like having separate Accounting, HR, Legal, 
Cleaning, Training, and Travel departments for every department — 
is what SOA ultimately eliminates. This lack of redundancy gives 
you the same obvious benefits of scalability, consistency, and 
maintainability. 


With SOA, business managers work with IT to identify business 
services. Together, they determine policy and best practices. 
These policies and best practices become codified business 
services that represent honed company business processes. No 
need, for example, to have 30 different variations on an exchange 
rate translation application, each used by a different department 
and all requiring IT time for ongoing maintenance. One business 
service will do. Onward, the new world order! 
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Redundant reiteration, again 


For any IT old-timers out there who 
have labored long and hard in the IT 
trenches, the concept of software 
reuse isn't new. You're familiar with 
subroutine libraries and the great 
theme of object orientation, and you 
extol the virtues of standardization. 
“What's the big deal with SOA?” you 
ask. “Aren't we already doing this?” 
Well, yes and no. Yes, because the 
world of SOA depends on a good 
understanding of reuse and on the 
building of reusable components. No, 
because SOA extends the idea of reuse 
not only to Web services — software 
that uses standard Web interfaces to 


communicate with other software 
containing Web service interfaces — 
but also to business services — 
codified representation of a business 
function such as software designed to 
“prepare an invoice.” In the world of 
SOA, the level of granularity shifts 
profoundly. No longer are we talking 
simply about reusable low-level 
components: We're talking about 
reusable high-level business services. 
This shift, and its implementation, is no 
mean feat either for business managers 
or for IT, but the rewards for everyone 
are dramatic. 


Assuring a Getter Quality of Service 


If you’re ready to jump on the SOA bandwagon, just remember 
not to go it alone. You need to bring along some friends from IT 
and the business. In other words, you need to get others to buy in 
to the concept of beginning the SOA journey. You need to sell SOA 
and you need to focus on the benefits in order to get others to 
join with you. One of SOA’s greatest benefits is the ability to 
improve quality of service. Does that sound a little too pat? Well, 
maybe an example would clear up what we actually mean when 
we Say quality of service. 


Consider this example. Have you ever gone to a restaurant, and 
everything seemed to work just right? You called ahead and 
asked for your favorite table. It was ready for you when you 
arrived. The host was polite and called you by name. The 
temperature in the room was just right — not overheated and 
stuffy, but not air-conditioned to frigidity, either. The waitress 
was friendly and brought you water, rolls, and a menu. Service 
was fast, but not too fast. Overall, it was a smooth, positive 
experience. If anyone asked you, you would declare that the 
quality of service was excellent. 
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This kind of smooth, satisfying, efficient operation is precisely 
what businesses can achieve by using service oriented architecture. 
SOA adds predictability and regularity between business rules, 
policy, and software services. Therefore, one of the greatest 
selling points for SOA is that it can help management know what 
tasks a particular service is executing and what rules and policies 
are codified within these services. Being able to track this not 
only makes software within the company better but also makes 
corporate governance more predictable and less cumbersome. 
Now, maybe you're a skeptical person and think, “Wait, wait. I can 
do all this by having the developers write good modular code. I 
don’t need SOA.” In a certain way, of course, you would be right. 
The difference is that when change happens, you can be a lot 
more nimble with SOA. 


If you’re building services, you must design them to adhere to the 
following three requirements: 


1” They must be safe. Safe means that the service itself is 
secure and doesn’t introduce bugs and problems into the 
organization. 


They must be accurate. Accuracy means that the service 
itself executes the function it’s designed to execute. At the 
end of the day, accuracy is all about corporate governance. 
Organizations implementing SOA must be reassured that 
each business service is executing the right function in 
association with governmental regulations. 


v They must be predictable. Predictable means that the 
service does what it’s expected to do. If a service is 
designed to calculate a 30-year mortgage, it had better do 
exactly that each time it’s used; likewise, a service intended 
to pay a claim needs to execute the same process across 
many different composite applications. 


Educating Rita and Peter 
and Raul and Ginger 


No sane person spends time or money on something they don’t 
understand. Understanding how SOA can improve quality of 
service is a key selling point of SOA, but don’t make the mistake 
of including too many technical details as you begin to educate 
your company about SOA. (“How ’bout those Web Services 
interfaces!”) In selling SOA, you need to explain the business 
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benefits of the technology in layman’s terms. Be prepared to 
answer questions such as 


How will implementing SOA improve our ability to service 
our customers? 


How much will it cost? Will it pay for itself? How long will it 
take? 


1# Is this safe? How can we make sure someone won’t steal 
our data? 


Part of your education begins outside of your own company. Find 
peers of your organization’s managers in other organizations who 
have successfully taken the plunge. If a company that looks like 
yours has been able to begin its SOA journey, your management 
should take notice. One endorsement by a peer is worth at least 
ten return on investment pitches. 


Complying with Government 
Regulation 


Instituting and following a SOA approach ultimately makes an 
organization much healthier. When every aspect of IT is under 
SOA governance, regulatory compliance is a natural byproduct. 
So, if you know people in your organization who have been tasked 
with making sure that the company is adhering to guidelines for 
the Sarbanes-Oxley Act, HIPAA, Basel II, the Gramm-Leach-Bliley 
Act, or any other regulatory or policy-based requirement, you may 
want to talk to them about SOA. After they understand what SOA 
can do for them, you’re likely to have allies. 


Making SOA Happen 


We show major components of a service oriented architecture in 
Figure 1-1. We provide an overview of these components in this 
section, but recognize that you may have more questions than 
can be fully answered here. You can find lots more detail on the 
components that make SOA happen in our big book on this topic, 
Service Oriented Architecture For Dummies, 2nd Edition. 


The Enterprise Service Bus (ESB), the SOA registry and repository, 
the business process orchestration manager, service broker, and 
SOA service manager each have a role to play, both independently 
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and with each other. The ESB makes sure that messages get 
passed back and forth between the components of a SOA 
implementation. The SOA registry and repository contain 
important reference information about where the components of 
a SOA are located. The business process orchestration manager 
provides the technology to connect people to people, people to 
processes, and processes to processes; the service broker 
connects services to services, which in the end, enables the 
flow of business process. 


, Business 
Business Process 


Process 


Business 


App 1 
Business 


F2 Function 1 


Orchestration 
Layer Manager 


Enterprise Service Bus 


SOA 
Registry 


Infrastructure 
Services 


Service 
Broker 
SOA Service 
Manager 


Figure 1-1: Fundamental SOA components. 


The role of the SOA service manager is to make sure that the 
technology underneath the SOA environment works in a 
consistent and predictable way. The goal is to create an 
environment where all these components work together to 
improve the flow of business process. All these services are 
required to link unrelated technology components as though 
they were designed to work together. 

MBER ; 
When all these component parts work together and sing the same 

tune, the result is dependable service levels. A finely tuned SOA 

helps guarantee service levels. 
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Catching the Enterprise Service Bus 


In service oriented architectures, all the different pieces of 


software talk to each other by sending each other messages — a 


lot of messages. The messages are critical to delivering end-to- 
end service. They must be delivered quickly, and their arrival 


must be guaranteed. If that doesn’t happen, “end-to-end” service 


quickly becomes “lack of service.” 


To transport the messages between software components, SOAs 


typically use an ESB. The ESB is so important to SOA that some 
people think that you can’t have a SOA without one. Other folks 


think that if you have an ESB, you have a SOA. Neither statement 
is accurate. You don’t need to have an ESB to have a SOA, but you 


do need a way for the services to communicate with each other. 


The ESB is a reasonable and effective way to accomplish this goal. 


You can think of an ESB as a special layer that runs on top of the 


network and provides a guaranteed messaging service for the 
most important messages on the network, including the 


messages that the components of SOA continuously send to each 


other. 


Usually, in architecture diagrams, the ESB is represented as a 
separate pipe through which information and instructions flow. 


(Refer to Figure 1-1 to see what we mean.) In reality, it’s not really 


a pipe. Rather, the ESB is a collection of software components 


that manage messaging from one software component to another. 


A software component connects to the ESB and passes it a 


message by using a specified format along with the address of the 
software component that needs to receive the message. The ESB 


completes the job of getting the message from the sending 
component to the receiving component. 


Welcome to the SOA registry 
and repository 


Somebody — or something — has to keep track of all the 
available business services that you created to represent your 
most important business processes. All those reusable 
components have to be recorded somewhere, and that 
somewhere is the SOA registry. 
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Think of the SOA registry as a kind of electronic catalog where 
you store information describing what each component does. It 
has two roles: 


One rooted in the operational environment 


One rooted in the world of programmers and business 
analysts 


In the operational environment, the SOA registry provides reference 
information about software components that are running or 
available for use. This information is of particular importance to 
the service broker — the software in a SOA framework that brings 
components together by using the rules associated with each 
component. 


For programmers and business analysts, on the other hand, the 
SOA registry acts as a reference that helps them select components 
and then connect them to create composite applications that 
represent business processes. It also stores information about how 
each component connects to other components. In other words, 
the SOA registry documents the rules and descriptions associated 
with every given component. 


The SOA registry is extremely important because it acts as the 
central reference point within a service oriented architecture. 
The SOA registry contains information (metadata) about all the 
components that the SOA supports. For that reason, it defines the 
domain of the architecture. 


The SOA registry is where you store definitions and other infor- 
mation about your software components so that developers, 
business analysts, and even your customers and business 
partners can find the services they need. Business services are 
published in a registry to make them easier to find and use. 


The idea of publishing Web services is critical to SOA. You can 
only reuse services that are available for reuse, which means they 
have to be published first. 


Comparatively, the repository is like a central reference point 
within the software development environment. It stores the 
source code and the linking information used to build all the 
programs that run in the operational environment. The SOA 
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repository feeds the service oriented architecture with changes 
and new components. The SOA repository works within the 
operational environment and takes on the responsible role of 
acting as the counterpart of the registry within the development 
environment. 


Simply, here’s the difference between the repository and the 
registry: 


Repository: Central reference point for all the components 
within the software development environment from which 
services are built 


1# Registry: Central reference point for definitions, rules, and 
descriptions associated with every service within a SOA 
environment 


Managing business processes under SOA 


With all this discussion of registries, repositories, brokers, and 
buses, we want to remind you that the whole point of SOA is to 
make a business more manageable, more flexible, and more 
responsive to change. The primary culprit when it comes to 
instigating change is business process: how businesses do things. 


Businesses constantly change how they do things while not 
necessarily changing what they do. For example, an insurance 
company might change the methods it uses to introduce new 
products or how it handles insurance claims, but when all is said 
and done, it still sells insurance. SOA enables business people to 
change business processes without having to focus on the 
underlying technological plumbing. You can concentrate on 
designing and improving business processes by threading 
together business services. IT can build composite applications 
from existing business functions, adding other functions or 
making changes where necessary. Together, business and IT can 
determine the flow of work from one person to another (or from a 
person to a process or from a process to a person) within the 
larger business process. 


“But how do they do that exactly?” you may wonder. Thanks for 
asking. With all these business processes to manage, the 
somewhat obvious solution is business process management 
(BPM). BPM is the modern approach to designing and managing 


These materials are the copyright of Wiley Publishing, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


R 


Chapter 1: Getting to Know SOA 15 


business processes, and many business managers and business 
analysts receive BPM training. All by itself, BPM has contributed 
significantly to the liberation of business from technology. 


Whereas BPM focuses on designing business processes 
effectively, SOA is an architecture that conveniently allows IT to 
align with business processes. It’s only natural — yet very 
important — to successful implementation of SOA that SOA and 
BPM have converged, with BPM software tools becoming a 
natural part of aSOA development environment. Coupled with 
SOA, BPM is doubly powerful. 


Choosing a Test Case Carefully 


After you have some buy-in (notice we aren’t asking for unilateral, 
unanimous, unmitigated buy-in — just some buy-in), you want to 
pick a project that’s relatively small in scope that can quickly 
prove the merits of SOA. Every organization has a lot of projects 
that would make great SOA candidates. Be careful to pick an 
important project that’s both doable and important enough to get 
management attention and that can be completed in a relatively 
short time frame. We know of at least one company (that we 
aren’t allowed to mention) that saved more than $40 million in 
just three months. Maybe you can’t find something quite so 
dramatic, and you may need help figuring out what project will 
bring the quickest big yield, but our point is that you should pick 
your early SOA projects carefully. Early SOA success is critical to 
gaining more buy-in. 


gore One of the most exciting benefits of SOA is that there isn’t just 
one way to start. Depending on your business issue and the 
nature of your industry, you can achieve business benefit in a lot 
of ways. For example, are you in a company where a lot of 
knowledge is residing only in people’s heads? Is there a danger 
that knowledge might walk out the door unexpectedly? Are some 
of the most knowledgeable people getting ready to retire? If you 
answer “Yes” to questions like these, it may be important to start 
by working to extract the knowledge and processes that people 
carry around in their heads and make that information into 
business services with clearly defined interfaces. 


On the other hand, you may have a situation where the processes 
and rules of the business are well-documented in various appli- 
cations, but these software applications are associated with 
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different departments and located in different places in the 


company. This disaggregation of each department and its specific 
applications representing business processes and rules makes it 
difficult for one application to access another. So even though the 
rules of the business are well-documented, you still have some 
work to do. The processes and rules of the business should be 
articulated in reusable business services that can be consistently 


used across the different departments of the organization as a 
way of improving governance and oversight. 


Or you might have a common service that is implemented in 500 
different ways across hundreds of applications. You may want to 
start by creating some shared services that can replace these 500 
different services. Or you may want to put a registry/repository 
in place so that everyone can find the right authorized service. 


Other organizations may gain value from simply discovering 
exactly what assets they have in their IT systems. The point is 
to pick your starting point based on the issues that are most 


important to your company. (And remember that such starting 
points may not necessarily be the most sophisticated features of 


the organization but yet may still have significant business 
values.) 


The Case for Case Studies 


Aside from introducing SOA, we describe the benefits and how to 
sell the benefits to others so that they support efforts that your 


organization makes to adopt a SOA strategy. We could provide 


you with a lot more detail on the subject, but in the end the proof 


of the pudding is in the eating. In the next seven chapters we 


report on seven companies that have used SOA in their own ways 
for their own benefit. We describe what was achieved and how 


they achieved it. 


We think this will help. With new technology ideas and new 
business methods it is always comforting to know that others 


have been successful in making them work. The company case 


studies in the following chapters represent a cross section of 


industries: financial services, healthcare, travel and hospitality, 
manufacturing, retail, telecommunications, and energy/utilities. 
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Financial Services 


In This Chapter 
Understanding CIGNA’s business initiative for SOA 
Looking at why financial services companies need SOA 


Viewing lessons learned and best practices 


M any companies in the financial services market segment 
have been early adopters of new technology. The various 


company types included in this sector — banks, insurance, invest- 
ment, and brokerage companies — all have a common need to 
manage very large amounts of data very fast, with a high degree of 
security and accuracy. Advanced technology has been leveraged 
to support an increasingly complex network of global financial 
transactions managed by the financial services industry. However, 
as the global financial crisis of 2009 underscores dramatically, 
even the most sophisticated use of technology can play only a 
supporting role to the business decision makers leading the 
business. 


The need for the new world order of technology we discuss 

in Chapter 1 is intensified by the challenges of economic 
discord. There is an urgent need for “smart” business decision 
makers who are able to cooperate with a “smart” IT team to 
make even “smarter” decisions. The complexity of the technology 
infrastructure at many companies in the financial services sector 
makes it very hard to leverage IT services in a coordinated way 
across the enterprise. Many large companies have either merged or 
acquired other very large companies resulting in the integration of 
new business units with very different work cultures and widely 
different information infrastructures. The need to be able to trust 
and understand the information about the business across its many 
disaggregated parts has been a prime motivator for change in the IT 
infrastructure at these companies. 


Financial services companies require strong, supportive, and 
well-integrated IT infrastructures to manage future change. The 
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industry needs to be able to become more customer focused, 

to respond to increasing levels of regulatory compliance, to 
continue to build up levels of security and privacy surrounding 
financial transactions, and to provide increased attention to fraud 
prevention. 


Given the complexity of the IT infrastructure in many financial 
services companies, it’s no wonder that they have been some of 
the pioneers of the SOA movement. Companies like CIGNA, which 
is highlighted in the case study in this chapter, recognize that 
having the ability to take existing business logic and turn it into a 
business service can become a strategic advantage. 


ay? We think that the most important parts of the discussion of real-life 
experiences with SOA are the lessons learned. Because companies 
have had both success and failures, they have a lot to teach all of 
us about how to do SOA in a way that brings financial and business 
benefits. So read on and get smart about SOA. 


CIGNA 


“Think like a business person” is a message that resonates with 
the IT folks at CIGNA. In fact, this philosophy has fostered a 
partnership between business and IT at the company and helped 
to make it successful. So, when CIGNA Group Insurance — the 
part of CIGNA that manages disability, life, and accident insurance 
products — realized that it needed to fundamentally shift how it 
viewed its customers, IT was on top of it. 


Historically, CIGNA viewed its primary customers as corporate 
employers who purchased products and services on behalf of 
their employee population, their beneficiaries, and their dependents. 
Several years ago, CIGNA began to evolve its thinking around this 
to address employer concerns over the ever-increasing costs of 
employee benefits, particularly in the healthcare space due to the 
trend of skyrocketing medical costs. To address this issue, CIGNA 
looked to leverage its data assets, along with its clinical and 
vocational expertise. 


As a result, CIGNA continues to focus on the core capability 

of processing claims, while at the same time placing greater 
emphasis on providing products, services, and data assets that 
help keep individuals healthy. By proactively addressing — and 
in some cases predicting — medical conditions before they 
become serious, medical costs tend to decrease, fewer people 
take disability leaves, and work-related absences are better 
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managed. In a nutshell, sharper focus is placed on the individual, 
not just the employer, and everyone wins. 


This all sounds good on paper. However, CIGNA had supported 
its traditional customers — the employers — using an account 
management structure that didn’t lend itself easily to directly 
dealing with the individual population. CIGNA had developed 
many of its systems to support innovations to launch new 
products and services as well as deal with immediate business 
capability gaps in its current systems. The result? Over time, 
CIGNA built a complex infrastructure using a variety of different 
technologies. The company needed to change its underlying 
infrastructure and architecture to support this new individual- 
centric business view, but it knew it couldn’t simply replace all of 
its systems. A service oriented architecture (SOA) provided the 
means for CIGNA to incrementally move away from its legacy 
environment. At the same time, it enabled the company to 
introduce new business functionality. 


Business and IT Cooperation 


The architecture team realized that to solve the business 
problem, it needed to bring the thought process up a level from 
services and instead develop a more business-focused enterprise- 
level architecture. To do this, the architecture team is using what 
Brian Mitchell, chief architect for CIGNA Group Insurance, calls a 
“capability mapping and modeling approach.” The team is defining 
core business capabilities and then mapping these capabilities to 
core business functions and end-to-end business processes. It’s 
looking at how business functions map to the products and 
services that the company sells, and it’s also evaluating how 
products and services are distributed in the marketplace. By 
carefully defining and grouping related business functions, the 
architecture team has established a number of enterprise services 
in its overall SOA. 


So how does this all work? CIGNA’s enterprise architecture has 
defined several hundred business capabilities, each defined in 
terms of one or more business functions. A business function is 
like a mathematical function in that it takes in several input 
parameters and produces a single output parameter. For example, 
the calculate benefit business function is needed in support of 
several enrollment, eligibility, medical underwriting, self-service, 
and claims business capabilities. This business function 
determines for a particular individual (the input) the benefit 
structure (the output) for the products and services that have 
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been purchased from CIGNA. For example, it can help determine 
whether an individual is eligible for a flat amount of $100,000 of 
life insurance or entitled, instead, to receive a multiple of his or 
her salary as a life insurance benefit. This function is defined in 
CIGNA’s enterprise service for managing benefits for individuals, 
called Consumer Service. This process of grouping related 
business functions resulted in the definition of all of CIGNA’s core 
enterprise SOA services, and it helped determine the necessary 
responsibility and functionality each service needed to have in 
the end-state architecture. All in all, CIGNA defined and mapped 
more than a thousand business functions into approximately a 
dozen enterprise services. 


So, whereas the business had thought about eligibility and 
enrollment as two completely different functions, from an 
enterprise architecture perspective with a lens on the individual, 
they are one. The SOA framework allows CIGNA to orchestrate a 
series of business-process-aware services around the individual — 
one for enrollment, one for eligibility, one for billing, and so on. As 
an example, the enrollment service will interact with the consumer 
service to determine the benefits that an employer has purchased 
on a particular individual’s behalf, as well as determine any 
additional benefits for which an individual is eligible to purchase 
directly. Currently, the team is building out most of its individual- 
related service interfaces using the Human Resources XML (HR- 
XML) schemas. HR-XML is a library of XML schemas developed 
by the non-profit HR-XML Consortium. These industry-standard 
schemas support a number of business processes related to 
benefits administration and human resources. 


A unique aspect of what CIGNA did to make this architecture 
more business-focused was to work with the business directly. 
The members of the architecture teams met with their business 
counterparts on a regular basis. They participated in business 
strategy and planning meetings and partnered with their 
counterparts to better understand their business issues. The 
team even briefs the division president. Through this level of 
engagement and two-way dialogue, IT asserted itself as a more 
valued business partner and showed the business how IT can 
improve overall business capabilities, not just solve localized 
problems on a reactive level. 


CIGNA has a good view of the enterprise architecture and how 
the components eventually integrate. The team is making sure 
that each individual project is being designed and developed in a 


These materials are the copyright of Wiley Publishing, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


Chapter 2: Financial Services 2 1 


fashion where they can eventually hook services together. As 
CIGNA builds out its new capabilities, it is redirecting existing 
legacy systems to use and integrate with the new services or the 
underlying databases to support these enterprise services. In this 
way, CIGNA is able to move forward thoughtfully and incrementally, 
and not risk breaking legacy systems. 


Architecture team members are quick to point out that they 
didn’t invest in SOA strictly for reuse because they don’t think 
about services this way. Rather, CIGNA views the primary benefit 
of SOA as extensibility, so that a service built to meet today’s 
needs can evolve to meet future requirements. It’s also common 
to have requirements where enterprise services need to behave 
somewhat differently in different business scenarios. By using 
what’s commonly referred to as a message-centric approach 
toward service design, a developer can add further attributes or 
behaviors to the services without endangering backward 
compatibility by updating the service’s interface schema. 


Lessons Learned and Best Practices 


CIGNA believes that taking a business-focused approach helps 
make its SOA effort successful for the following reasons: 


SOA can help solve a real business need. In CIGNA’s case, 
one primary driver was repositioning technical capabilities 
more around the needs of the individual in support of 
CIGNA’s overall health improvement strategy. 


1# Ata high level, the business understands the benefits of SOA 
in business terms — such as cost reduction and efficiency. 
For example, service-enabling the systems used by the 
contracting department will also enable CIGNA to implement 
new cases faster by improving the integration with the 
existing legacy systems and providing them with accurate 
post-sale data from a single source. 


The enterprise architecture helps the business see that services 
built for one part of the business can also be used and 
extended for other parts of the business, thus benefiting 
everyone. Projects are now defined in terms of the entire 
business. In other words, CIGNA is now positioned to build 
capabilities that better support up- and down-stream business 
processes, instead of simply focusing on building localized 
departmental functionality. 
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Chapter 3 
Healthcare 


In This Chapter 


Looking at Independence Blue Cross’s initiative for SOA 
Understanding why healthcare needs SOA 


Viewing lessons learned and best practices 


n many ways, the delivery of healthcare is still a cottage 

industry. Although there have been enormous technological 
advances that help physicians diagnose diseases at an earlier stage 
and improve the overall quality of care, a positive patient outcome 
after a medical emergency often boils down to whether the facility 
you're being treated at has your medical records. Traditionally, 
healthcare facilities — from independent physician offices to clinics 
and hospital departments — have been siloed to an extreme. 
However, in order to get excellent care, your care providers, payers, 
and drug providers need to cooperate and this requires on-demand 
access to your medical history. If the healthcare industry is to 
function more efficiently, then the availability of care needs to be 
tied into the availability of data about the patient. 


Physicians make use of large amounts of time-sensitive data when 
caring for patients — including results of lab tests, pathology 
reports, X-rays, and digital imaging. Many hospital systems have 
deployed integrated systems for delivery and storage of results 
from various medical tests. The patient’s medical information also 
needs to interface with hospital billing systems for payment by 
third-party payers. In addition, there may be tie-ins to drug 
delivery systems so that there can be an online record of what 
dose of what drug has been administered to patients at what time. 


However, there are many hospital systems that fall far short of 
integrating all the medical information needed to speed the 
delivery of healthcare for the patient. What these systems are 
generally lacking is the ability to provide an integrated and 
comprehensive source of patient data that follows that patient 
wherever and whenever they need healthcare. Therefore, one 
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reason why large hospital systems, medical insurers, and 
pharmaceutical companies are moving to SOA is to help break 
down the silos of medical data in order to provide an integrated 
network of high quality care for patients. 


Of course, there are many reasons why the heathcare industry is 
moving to SOA. The healthcare industry has many challenges, 
ranging from issues related to privacy legislation to the need to 
provide more holistic patient care for less money. Healthcare 
insurance providers need to manage the relationships with both 
providers of healthcare and the needs of consumers. Pharmaceutical 
companies need to successfully leverage data and best practices 
across the entire healthcare ecosystem to ensure that they’re 
developing medicines that address emerging needs. 


Healthcare organizations are looking to SOA to allow them to 
more easily link business services and data across departments. 
They are implementing SOA to improve the level of cooperation 
between healthcare providers and payers and to improve 
outcomes to their constituencies. Service orientation has started 
to have a major effect on healthcare. 


Independence Blue Cross 


All healthcare companies are looking to reduce costs to balance 
expenses and maintain a reasonable cost of healthcare, and 
Independence Blue Cross is no exception. Independence Blue 
Cross and its subsidiaries are the Philadelphia region’s largest 
health insurers, with more than 3.4 million overall members. The 
company offers products and services such as Managed Care, 
Traditional Indemnity, Medicare, and Medicaid. Independence 
Blue Cross processes more than 32 million claims a year and 
responds to more than 6 million customer inquiries. 


A service oriented architecture has become an important part of 
this cost reduction strategy. SOA has provided high value to the 
company, while reducing costs associated with application develop- 
ment. In fact, it has changed the way application development is 
done at Independence Blue Cross. It was a “leap of faith” that 
Independence Blue Cross needed to make this change, according 
to Thomas Cangelosi, Director of the Infrastructure Integration 
Services department at the company. 
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Strategic SOA 


Independence Blue Cross began to deploy its SOA strategy about 
two years ago. According to Cangelosi, the company got off toa 
quick start with SOA because it had strong support at the highest 
levels of management. However, support and funding alone can’t 
guarantee success because SOA has implications other than 
technology, and its introduction brings a new level of social 
complexity and organizational change. What did Independence 
Blue Cross do to ensure success? The first step was to create a 
governance model. The second step was to help the application 
developers understand the value behind SOA and then actually 
use the approach. 


A good example of SOA in action is claim status. Say you go toa 
physician and want to know whether your claim has been paid. In 
this case, you might call the customer service agent at Independence 
Blue Cross to find out. Or you might call the billing department at 
the physician’s office. Or you might simply go online to check 
yourself. The front-end system might be different in all three 
cases, but the back-end uses the same service. It may be that the 
service may cross multiple systems to get the information; but in 
another case, it may use only one. The point is it is still the same 
service, so there is only one version of the truth. 


So, in many respects, Independence Blue Cross was fortunate 
that it got off on the right foot with SOA from the start. 


Step 1: Governing SOA 


At Independence Blue Cross, the governing committee is a multi- 
disciplinary body, consisting of technical subject matter experts 
from six areas across the business, including claims, enrollment, 
marketing, finance, project management, and technology. The 
initial focus of the committee was to establish a set of low-level 
foundation services. One example of this type of service would be 
a mapping service that maps proprietary provider numbers with 
government-issued National Provider IDs (NPIs). All the rules 
codified by the governance committee are stored in the 
company’s registry. 
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Cangelosi’s group chairs the committee but doesn’t get a vote. 
The business experts were the stars of the show and made the 
governance decisions. The group first put together an initial 
document that outlined processes and the life cycle of a service. 
It took several months to finalize a draft, and they took it to 
senior leadership, where it was iterated and ultimately ratified in 
two weeks. Cangelosi’s group has been given the leverage to 
make sure this gets enforced. 


From a governance standpoint, Independence Blue Cross 
established a policy from day one that a service was a service 
only if it was used more than once. The company realized that 

it could ultimately save a lot of time and money by developing 
reusable, standardized services. An important aspect of an 
enterprise-wide approach is assigning responsibility for service 
development and maintenance. The individual IT support 
function for each line of business builds the services and then 
supports those services. For example, if a service is pulling 

data from a provider database, the provider IT department 

has stewardship for that data. The provider department has 
responsibility to develop that service, pull data out, and get it to 
the service. Ultimately, they’re responsible for anything that goes 
against that system. 


Step 2: Application Developers 
Take a Leap of Faith 


With a governance and support plan in place, all that was left to 
do was convince the developers that SOA was the way to go. 


According to industry statistics, almost a third of all application 
development is focused on integration issues. Not surprisingly, 
Independence Blue Cross focused on SOA integration at the 
outset. Prior to the movement toward SOA, integration was part 
of the process of developing an individual application. Cangelosi’s 
group told the developers that they didn’t need to worry about 
programming their applications to deal with getting the data from 
point A to point B. Likewise, the developers were told all they 
needed to know was what data they were requesting from a 
service. So, they didn’t really need the service for their own 
development process: They simply needed to know what they’re 
requesting and what they will get back. 
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Developers hate change, and they hate losing control. Therefore, 
the move to SOA was a big cultural change for developers. 
Cangelosi determined that he would have to convince the 
developers to trust that SOA would be helpful and get rid of 
annoying and time-consuming tasks. Before SOA, all development 
was tied to an application. Developers were used to doing a direct 
connection to a database. This was no longer allowed. If a 
developer was going to get data, he or she needed to access it via 
a service. 


Management’s responsibility was to demonstrate to the 
developers the value in the new approach. If the developers 
perceived that the approach was a bottleneck, it wouldn’t be 
successful. Although changing a methodology is difficult, 
Independence Blue Cross noticed that after the developers 
realized that something that used to require four weeks now 
required only three weeks, they began to see the value and 
jumped on the bandwagon. As the services were built and 
developers started to use them, they began to see how a SOA 
approach added value from a productivity perspective. 


To this end, Cangelosi’s group is seeing a rapid increase in the 
number of services being requested from various groups in the 
company. Discipline is maintained because developers are seeing 
the value in the approach. For example, Independence Blue Cross 
was developing an application that needed to determine the status 
of a claim. Rather than writing this code from scratch, two different 
development groups got into the act. One group developed the 
claims status service, while another group built the front end for 
the application. These development groups worked in parallel. 
When the group was ready to use the claims status service, the 
developers were able to find it easily because it was exposed as a 
service on the enterprise service bus. As Cangelosi put it, “It was 
a perfect match.” 


What’s Next for IBC? 


Independence Blue Cross put a three-year road map together last 
year. With the first governance stage completed, the company is 
now embarked on the second phase. 


This second phase includes a process to automate the 
governance process. It will also focus on the ability to measure 
how well SOA is working. Measurements will provide answers to 
questions about how services are being consumed and how they 
add value to the company. The registry, which was implemented 
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in the first phase, will help the company capture metrics on use 
of services. The active registry will provide information about 
how services are being used and the retirement of existing 
interfaces. Today, this is being done manually. 


In 2009, Independence Blue Cross will implement the third phase 
of the SOA plan. The focus will be on two critical areas: Master 
Data Management and Business Process Monitoring. With Master 
Data Management, the company will focus on creating a common 
set of data elements across the company, so there can be a “single 
version of the truth.” Because the company is starting to have a 
strong catalog of well-designed services, it will be necessary to 
monitor how these services are linked into a business process. 
Monitoring the state and effectiveness of these processes will be 
important to managing how these services are used in specific 
business situations. 


Lessons Learned and Best Practices 


Cangelosi attributes the company’s success with SOA to three 
main practices: 


Taking an enterprise-wide view with executive support: 
According to Cangelosi, “We have been successful where we 
have seen other people trying to do the same that have not 
been successful.” Others weren’t successful because they 
couldn’t look across the enterprise. So, using that approach 
and getting executive backing on it is very important. 


Separating the technology from the methodology: The 
governance put in place is technology agnostic. The 
company doesn’t care what technology it has under the 
covers; its governance method will be the same across the 
board. 


Federated governance model: The fact that the governance 
committee consists of multiple groups across the company 
ensures that all aspects of company business are taken into 
account. It also provides varying perspectives. This further 
enables the enterprise view. 
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Travel and Hospitality 


In This Chapter 
Understanding the SOA plan for InterContinental Hotels Group (IHG) 
Looking at why travel and hospitality companies need SOA 


Viewing lessons learned and best practices 


Ml A re you traveling for business or pleasure?” This simple 

question can’t possibly describe the very complex 
market segmentation that exists in the travel industry today. 
Consider just a few examples of various types of accommodations 
or travel experiences: green hotels and eco-focused travel, high- 
end luxury spas and resorts in exotic and remote locations, trendy 
new pod hotels offering budget travelers tiny sleeping spaces 
with shared common areas, and grand all-inclusive resorts 
catering to business events. Many of the largest hotel-management 
companies operate multiple brands, catering to a broad range of 
these varied market segments. Intense competition and a high 
rate of mergers and acquisitions have contributed to an environment 
where a diverse group of hotel properties are managed by one 
parent company. In the past, large hotel-management companies 
commonly had individual hotels or groups of hotels that functioned 
as independent business units. But what happens when you want 
to optimize profitability and improve customer satisfaction and 
guest loyalty across all brands within the enterprise? 


A large, distributed hotel organization can find it impossible to 
leverage all the important information it’s collected about guests 
and hotel properties if the data is highly distributed and inconsistent. 
Typically, information about guest preferences, customer billing, spa 
services, restaurant services, and room availability have been 
managed at the property level and were often not standardized 
across a diverse hotel enterprise. In this highly competitive industry, 
large companies need a way to increase the value they receive from 
one of their most important assets: namely, information about the 
needs of guests and the operation of the hotel. Integration between 
the various systems that manage this information is critical to 
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deliver this information accurately and on time and to help 
manage the customer experience. 


In this chapter, we highlight InterContinental Hotels Group (IHG), 
a hospitality industry organization that manages numerous hotel 
chains. IHG implemented SOA to improve the flexibility of its IT 
infrastructure and to improve overall customer experience. 


InterContinental Hotels Group 


InterContinental Hotels Group (IHG) is one of the world’s largest 
hotel groups and includes such brands as InterContinental Hotels 
& Resorts, Crowne Plaza Hotels & Resorts, Holiday Inn Hotels & 
Resorts, Holiday Inn Express, Staybridge Suites, Candlewood 
Suites, and Hotel Indigo. It also manages Priority Club Rewards, 
which is the world’s largest hotel loyalty program, with more 
than 37 million members worldwide. IHG manages over 4,000 
hotels in more than 100 countries and opens new hotels daily. 


The hotel business is competitive. Customer satisfaction is 
critical, and expectations are high. Although the customer 
experience begins when the customer books a reservation, the 
ecosystem involved is quite complex and dynamic. IHG works 
with many channels to service its customers, including hotels, 
the Web, call centers, travel partners, global distribution 
systems, travel agents, and other intermediaries. Information 
such as room rates, room availability, and guest profiles must be 
immediately available to these channels. A service oriented 
architecture ultimately provided the agility and efficiency IHG 
needed to better serve its customers and move information 
through its channels. 


Distributing Key Channel Information 


IHG began its journey to SOA in 2002. The company faced 
several technical challenges, including a requirement that key 
information (such as Guest Profile, Room Rate, and Loyalty Unit 
Balance) must be available to multiple company channels 
simultaneously. At the time, according to Eric Norman, Director 
of Infrastructure Integration at IHG, the hotel industry hadn’t yet 
grasped SOA’s basic tenets. He thought that a service oriented 
approach could be well utilized by hotels, but there were few 
roadmaps or best practices to light the new path. 
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It was clear that a centralized computing platform — or even a 
distributed computing environment — would not be lean and 
limber enough to take on IHG’s wide array of ever-changing 
data. The architectural solution had to be agile, flexible, and 
extensible; it had to be technology- and vendor-independent; and 
its components had to be interoperable, composable (able to be 
built into larger components), and reusable. IHG implemented a 
number of projects using a SOA-based approach but fell short 

of expectations, partially because the team approached SOA 
from a development (bottom-up) perspective — a very common 
approach for many companies. From this perspective, services 
aren’t leveraged across the company because these services are 
just built to address a particular need. 


The journey was, therefore, an evolution, rather than a revolution. 
CIO Tom Conophy joined IHG in 2006, and he understood the 
challenges of implementing a service oriented solution in hotels. 
He had led a successful SOA initiative at Starwood Hotels and 
wanted to extend this vision at his new venture. To jumpstart it, 
he created a special Enterprise Architecture Group (EAG) whose 
initial focus would be the development of a SOA at IHG. The group 
included Conophy, his direct reports, and a cross-disciplinary 
Enterprise Architecture Workgroup (EAW). 


Conophy also initiated an Enterprise Architecture Team (EAT), 
placing it at the core of the EAG. The team was championed by 
Bill Peer, Director of Enterprise Architecture in IHG Global 
Technology, and comprised system, infrastructure, governance, 
and solutions architects. (Each architecture group specialized in 
a particular facet of the SOA.) The group’s objective was to 
develop a SOA-based solution for the company that leveraged 
extensible, composable, and reusable services based on JHG’s 
business model. 


Peer’s team aggressively sought out tools and drafted standards 
to engineer a robust, agile new SOA solution that would eventually 
provide a roadmap for the company. After months of research, 
software evaluation and testing, and consultation (with technology 
companies, businesses inside and outside the hotel industry, and 
internal IHG resources), the EAT completed a SOA that is now 
used to develop services accessible across multiple business 
units at IHG. 
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SOA Implementation Highlights 


IHG’s SOA relies on an enterprise service bus (ESB), which enables 
the rapid integration of services that can be exposed to multiple 
business units. The ESB uses an orchestration engine to define the 
sequence of such important services as MakeReservation and 
CommunicateWithGuest. Orchestration dramatically increases 
the power and flexibility of these and other pivotal IHG services. 
In addition, the ESB uses a centralized registry-repository, which 
standardizes policies and other service description artifacts, and 
which enables service discovery. 


For example, IHG’s Loyalty business unit may decide that it would 
like to send a seashell to every Priority Club member who books 
a room at a beach hotel. A new orchestration process can be 
created from the existing services SendGift and Communicate 
WithGuest. Because both services are stored in a federated 
registry-repository, they exist in a standard format that can be 
accessed and customized by any other IHG business unit. 


Reusable services are key to the success of IHG’s solution. A 
federated registry-repository is used to enable discovery of the 
services. To illustrate, consider how the SendGift service can be 
used to meet the goals of IHG’s Loyalty business unit versus 
those of Distribution Marketing. The Loyalty group manages IHG’s 
Priority Club program; Distribution Marketing’s goals include 
increasing reservations at IHG hotels. Whereas the SendGift 
service can be used by Loyalty as a small gesture of thanks to 
Priority Club members, it can be used by Distribution Marketing 
to send coupons or other incentives to IHG guests to ensure 
return visits. 


IHG services are composable as well. For example, IHG may 
determine that the MakeReservation and CommunicateWithGuest 
services are always called during the Reservations business 
process. The organization may then decide to create one new 
service from those two services. The new service, called 
ReserveAndCommunicate, will be composed of the 
MakeReservation and CommunicateWithGuest services. 
Composable services can (where applicable) yield simpler, 
leaner, more elegant programmatic solutions at IHG. 
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IHG’s SOA Reference Architecture: 
A Self-Healing Ecosystem 


IHG’s computing platform goes beyond implementing a SOA. It’s 
an autonomous, self-healing ecosystem that uses a dynamic 
resource broker to manage component instances (including 
starting and stopping of components, as well as managing 
components during peak conditions and low usage periods). 


The IHG reference architecture has the following capabilities: 


Transparent scaling of service container (the implementation 
of the service interface) instances across a shared 
virtualized hardware pool in a grid topology (hardware 
components that are connected to neighboring components 
in a grid). 


Centralized management used to automate the deployment 
and lifecycle management of system components. Software 
stack updates can be performed without suffering service 
outages. 


Runtime visibility into memory, CPU, threading, and other 
resource utilization, made available using dashboard views. 
This virtualized administration allows the entire fabric of 
system components to be managed as a single logical unit. 


Transaction state querying and root cause analysis, provided 
by the event stream processor. Performance metrics and 
usage patterns are available for determining the system’s 
state of health and for taking proactive curative measures. 


Lessons Learned and Best Practices 


Now that IHG’s SOA has evolved, it will continue to be used in 
development groups and will doubtless be refined as the months 
and years progress. During its exploration and adaptation of 
service oriented architecture, the IHG Enterprise Architecture 
Team learned several important lessons: 


Use standards and governance to manage the number of 
services and force their reuse. A couple of past IHG 
development teams had used anywhere from 200 to more 
than 1,000 services, which made versioning changes, 
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API-level changes, or client-level changes difficult, if not 
completely impossible. 


Don’t use a governance model that’s too structured. Use 
a registry and repository to centralize the storage and 
communication of service-oriented policies. However, 
maintain a more or less hands-off approach with individual 
project teams so as not to interfere with their specific 
development goals. 


Promote strong SOA tenets across the organization. Make 
sure that all development teams understand thoroughly that 
a SOA must be loosely coupled, interoperable, reusable, 
composable, stateless, and discoverable, among other 
features. This means, for example, that a mainframe system 
accessed by an application stack (even a Java-based one) is 
a middleware solution, not a SOA. 


1” Make sure services are rigorously tested. Best practice is 
to append an additional 10 percent to the testing phase; this 
gives you extra time to ensure that a wayward client can’t 
demolish a service. 


Peer emphasized what he considered the most profound insight 
gained during his group’s endeavor into SOA: “Education and 
communication of SOA help ensure buy-in from all levels in the 
company. Make sure that all parties with a vested interest in SOA 
have a thorough understanding of what it is and is not (both ina 
business and technical sense). Vendors, magazines, and pundits 
have polluted the term SOA, so invest heavily in comprehension 
before undertaking architecture and design. Sprinkle those who 
have a strong comprehension among the development teams that 
are delivering or using the services.” 
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Chapter 5 
Manufacturing 


In This Chapter 


Understanding Cisco’s business initiative for SOA 
Looking at why manufacturing needs SOA 


Viewing lessons learned and best practices 


mproving operational efficiency is a prime driver for success 

and profitability in the manufacturing sector. In addition to a 
sharp focus on operational efficiency, this sector is driven by two 
key needs: to reduce the cost of manufacturing goods, and to 
have a sophisticated and effective channel of distribution. 


In this chapter, we highlight Cisco, a computer and electronics 
manufacturer. Like many other companies in this sector, Cisco 
provides solutions directly to customers and indirectly through a 
complex partner channel. Therefore, it’s not surprising that 
technology innovation is at the core of how companies in this 
sector differentiate themselves. 


The advent of a service oriented manufacturing and distribution 
strategy has enabled companies in this vertical to be much more 
nimble in connecting partners, suppliers, and customers. These 
companies have leveraged online ordering, self-service portals, 
and integrated sales channel technologies. These companies face 
a stiff competitive environment, and view using SOA as a way to 
stay ahead. In this chapter, we show how Cisco developed 
specific business services that allow it to respond quickly to its 
partners’ requirements. SOA enabled the company to improve 
the way it provides service to customers, suppliers, and partners. 


Cisco 


You'd have to live in a cave not to know about Cisco, which is one 
of the world’s leading providers of hardware, software, and 
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service offerings for creating Internet solutions. Although best 
known for its IP-based network technologies, Cisco has 
dramatically expanded its business over time through strategic 
acquisitions. In adding companies such as WebEx and IronPort to 
the fold, Cisco had to evolve its systems to support multiple 
business models — including traditional product, Software as a 
Service (SaaS), subscription, and IT as a service offering — in 
parallel, and on a global scale. 


Realizing the impact that such changes would have on its 
ordering capabilities, Cisco IT embarked in 2006 upon a major 
initiative to transform how it conducts online commerce with 
both its direct customers and its significant partner community. 


Because most of Cisco’s products are sold through channels, it 
wanted to be sure there was a consistent user experience when 
placing an order, regardless of the product or service being offered. 
Not only did Cisco want to ensure process, data, and application 
logic consistency across its own customer and partner-facing 
applications, but it also sought to allow its partners to provide the 
same consistency through their individual customer-facing Web 
ordering tools. Cisco embarked on a SOA journey to make this a 
reality. 


Transforming to SOA 


Prior to the start of its Commerce Transformation initiative, like 
many early adopters of SOA, each IT group within the company 
had implemented a relatively disconnected series of Web services. 
Although each group did a good job developing its own system to 
support its business process, their approaches weren’t created 
with an overall enterprise architecture in mind. So the end result 
was that Cisco had a series of disconnected Web Service—enabled 
application silos that required too much complex coding to support 
needed integrations. “When you have a billion lines of software 
code, it actually should be called hardware because you can’t be 
very agile,” said Craig Hinkley, VP of Architecture and Technology 
at Cisco. 


Having learned some important lessons, Cisco IT changed its 
approach in 2006 to work more directly with the business to 
define the strategic objectives and the business processes that 
would deliver upon its Commerce Transformation vision of 
making it easier to do business with Cisco. 
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Vice President (VP) of Commerce IT Guillermo Diaz led a team 
that worked with the different business units to define the right 
starting points to enable business process agility through SOA. 
Rather than trying to boil the ocean, the team picked out a few 
critical business processes — pricing, discounting, configuration, 
and ordering — to develop as enterprise-wide services. The idea 
was to roll out individual services as pilots, obtain key wins with 
targeted applications, and then start to make them generally 
available to other parts of the business as reusable services. 


“Having built a number of discrete services associated with the 
commerce process, over time, we began the task of deploying 
these services to support our customers and partners,” said Diaz. 
These services included pricing (localized in 15 different 
languages), discounting, and product configuration, as well as 
identity and access management to securely extend the ordering 
process outside the company. 


One of Cisco’s biggest concerns was scalability. What would 
happen if too many partners tried to use the same service at the 
same time on the same network? “To ensure a positive user 
experience, it was critical that we looked at architecting services 
for our customers and partners that not only allowed for value- 
add customization, but that were reliable and consistent in their 
performance,” said Hinkley. To solve this problem, Cisco used a 
network-based acceleration service that could be deployed 
across a distributed environment to ensure consistency and 
scalability of their applications. 


Cisco thinks about measuring the value of IT and SOA across 
three dimensions: experience, productivity, and growth. Cisco 
wants a consistent experience around the application services it 
has developed across its different channels. One of the clear 
benefits of aSOA approach is that when a service needs 
modification, the experience is uniformly changed across all 

the channels. Another benefit is that the company can evolve 
composite business services faster than before because it now 
focuses on how to evolve each service component versus how to 
deal with functionality in a monolithic system. Finally, SOA affects 
growth because it gives Cisco the agility to respond quickly to its 
customers and partners. For instance, as designed, the pricing 
service allows the company to substantiate pricing rules that are 
needed for certain situations much faster than it could before. 
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Changing the Nature of 
Partnerships with SOA 


We don’t have to tell you that change isn’t always easy. Getting 
partners who are used to their own way of doing things to adopt 
SOA-based services can be difficult. 


Many of Cisco’s partners, for example, are accustomed to ordering 
products from its more traditional commerce Web site that helped 
propel Cisco’s early growth in the mid-to-late 1990s. These partners 
built their own tightly coupled software and processes to support 
this method of ordering. In essence, to make the transition to SOA 
take hold externally, Cisco has to sell its partners on the value and 
ease of use of this new approach. If partners adopt these new Web 
Services now, innovations and changes will be easier for them to 
deploy in the future. Cisco envisions that over the next few years, 
its partners will use the services it provides — and expose them 
as widgets or portlets to create their own online selling experiences 
using standard components from Cisco. 
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Chapter 6 


Retail 


In This Chapter 


Understanding Spotlight’s business initiative for SOA 
Understanding why retailers need SOA 


Viewing lessons learned and best practices 


[ee was a time, not all that long ago, when a retailer could 
expect consumers to walk into a store and make a purchase 
based on the visible choices. If the consumers didn’t like what they 
saw, they might check out the store across town or perhaps look 
through a few catalogs, but there weren’t many other options. 


That’s all changed. Today, retailers need to be able to anticipate 
how a consumer will want to interact with them at any moment, 
and they need to be ready to service that consumer through many 
different channels. For example, if a consumer wants to buy a 
complicated piece of technical equipment, she may choose to 
research prices and brands online and then make the purchase in a 
store. Or the consumer might decide to walk into a large store to 
ask a real person for advice and then go home to make a purchase 
from an online retailer who offers a better price. Retailers recognize 
that the increase in retail options has led to a consumer base with 
very high expectations about quality, price, and selection. In 
addition, customer loyalty is hard for any retailer to maintain 
when just a little online research can help a consumer to locate 
new brands, find the right color or size, or a better price. 


These trends in consumer behavior have helped to make an 
already competitive retail environment even more challenging. 
Although smaller stores still exist, the trend has been toward 
larger chains and giant multinational corporations. Many large 
retailers have grown even larger through multiple acquisitions 
across regional and geographic boundaries as they strive to 
expand their reach across the globe. Retailers of all sizes typically 
need to manage multiple channels of distribution including the 
store, catalog, and Web site. They need to market aggressively to 
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remain competitive across all these channels. In addition, to 
make sure that stores and warehouses are well stocked and the 
consumer can choose from a diverse group of products and 
brands, retailers need to partner with many different suppliers. 
This means managing large amounts of data and numerous 
interactions with partners and suppliers. The technology infra- 
structure is an important part of this equation. If a retail chain 
doesn’t know how much inventory it has, it will be in trouble. If it 
can’t analyze its data, it can’t market itself effectively. If its point- 
of-sale (POS) systems are outdated, it can’t be as efficient. You 
get the idea. 


The retail company, Spotlight, turned to SOA to help revamp IT 
infrastructure with a goal of providing a higher quality of service 
to customers. Insight into its success is highlighted in this chapter. 


Spotlight Pty Ltd 


“Legacy system spaghetti” is the phrase that Anne McDiarmid, 
Chief Information Officer of Spotlight Pty Ltd, uses to describe 
the old IT infrastructure at Spotlight Stores. Spotlight is a privately 
owned retail company with two brands — Spotlight Stores and 
Anaconda Stores. Spotlight Stores is one of Australia’s largest 
craft, fabric, and home interiors superstores. It sells everything 
from craft and fabric supplies to home furnishings to party goods. 
Spotlight has opened 106 stores across Australia, New Zealand, 
Hong Kong, and Singapore. It owns 12 additional Anaconda Stores 
that sell outdoor supplies for camping, fishing, hiking, and even 
skiing. Over the past few years, the company has experienced 
explosive growth. 


Although expansion of the business is most always a good thing, 
the IT infrastructure at Spotlight didn’t keep pace with the rest of 
the company’s growth. The result was that Spotlight had some 
real governance issues in terms of product and price. One of its 
biggest challenges was maintaining accurate visibility into product 
availability across all its stores. It lacked the infrastructure that a 
traditional retailer needs to support the customer at point-of-sale 
(POS) — on-demand information on product price, description, 
and availability. The company had many different systems held 
together with a multitude of middleware that on a diagram looked 
literally like spaghetti. 


So, although the company had managed to be successful despite 


the limitations of its infrastructure, Spotlight knew it was only a 
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matter of time before the situation got out of control. It knew that 
its POS systems wouldn’t support its expansion plans, and it knew 
that it needed to move past its home-grown enterprise resource 
planning (ERP) systems. Spotlight needed to upgrade its 
infrastructure — and quickly. The company management felt that 
the only way to accomplish this rapid change was to bring in 
outside expert help — and along with that help came SOA. 


Step 1: The Point-of-Sale System 


Why bring in an outside team? McDiarmid’s staff of 50 was so busy 
holding all the legacy systems together that they simply didn’t 
have the time to stop and try to figure out how to solve the issues. 
In 2006, McDiarmid brought in Australia-based KAZ Group Ltd. to 
help. KAZ is the largest Australian-owned IT services company, 
with 30 years of experience under its belt and an army of about 
1,500 employees. According to Vicki Redwood, a Solution Architect 
with KAZ, the goal was to try to establish control over Spotlight’s 
systems while at the same time introducing change. And the time 
frame for change was very aggressive — less than two years to 
change a number of critical parts of the business process, from 
installing a new multilingual POS system to deploying a major ERP 
system and enabling online commerce and communities of interest. 
The final requirement was that these changes could not impact 
downtime in any way because Spotlight is an event-driven business. 


The first step was to determine the “as-is” situation. The company 
had very little documentation about its systems. The KAZ team 
took about three months to map out the process of buying and 
selling to understand common processes across the company 
and the role of the legacy systems. 


After this was done, Redwood’s team got to work and developed 
a phased approach to providing the functionality Spotlight needed. 
The first part of the plan was to address the POS systems. POS 
systems are used by retail businesses to collect payments, track 
sales for analysis, and track inventory. The Spotlight system was 
fairly old and didn’t perform all these functions well. Additionally, 
Spotlight was opening new stores in Hong Kong, and its system 
didn’t support multiple languages. The plan was to implement a 
new POS system in Hong Kong and gradually phase out existing 
systems for the rest of the stores. The old system was tightly 
integrated with a multitude of middleware code that couldn’t 
support the new POS system. 
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Spotlight implemented a new POS system by using what Redwood 
refers to as a service separator layer: a group of services on a 
commercial process server that sits between the POS system and 
the back-end legacy system. This process layer could pass infor- 
mation between the POS system and the back office system. It 
also helped to provide consistency to various retail processes. 
One way that consistency of retail processes was improved was 
by establishing an alert system to identify errors and application 
problems, such as checking for the use of invalid product names 
or numbers in the ERP system. Finally, the process server also 
helped to save time and improve the accuracy of the POS check- 
out process by allowing for failed processes to restart from the 
point of failure. 


Step 2: The ERP System and Beyond 


The next phase of the SOA plan was to swap a series of Spotlight’s 
old home-grown systems for a commercially available ERP system. 
The number of home-grown systems had increased over time, 
and the result was multiple versions of the truth. For example, 
different divisions might show conflicting sales results or product 
or customer information. The plan was to implement an ERP system 
to provide a single version of the truth. Instead of implementing it as 
a monolithic application, the team was able to use a plug-and-play 
approach because of SOA. It simply implemented a series of service 
interfaces that talked to each module of the new system. As it 
brought new ERP modules live, it simply shut down the old legacy 
system. The process was transparent to the end user. Spotlight 
plans to implement a Customer Relationship Management (CRM) 
system in the same way. 


Spotlight is also moving to bring its ecommerce system online. 
The team plans to build on the common processes already in 
place for the POS system and to tweak them a bit for this channel. 
It’s also planning to implement a portal for a community of 
interest groups, such as quilters and other people interested in 
crafts. The portal will enable these people to work together. 


Choosing the Right Technology 


To deliver the required business process improvements, Spotlight 
needed a technology that would provide end-to-end control 
among a variety of business processes. This technology had to 
work for both the old and the new systems. Therefore, it was 
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necessary to develop interfaces between these systems: for 
example, between the legacy ERP systems and the new POS 
systems. In addition, the company needed interfaces between 
SAP software and warehouse management systems and logistics 
providers. Finally, the new e-commerce solution needed to work 
with the old ERP and legacy applications as well as the new SAP 
implementation. 


The technology also needed to provide processing improvements 
in the areas of performance, robustness, growth, audit, and security. 
It needed to be able to mediate between different services and 
applications as well as comply with industry standards. Finally, it 
needed to provide visualization capabilities of Spotlight business 
processes that would be used by both business and IT. And, of 
course, the business couldn’t be affected as new services and 
applications were added and old ones removed. 


So, how did Spotlight meet this list of requirements? The team 
selected an industry standard process server. It provided the 
following set of capabilities for Spotlight: 


Industry standard adapters to allow POS events (old POS 
and new) to be initiators, participants, or recipients in a 
variety of business processes without change to the POS 
applications. Adapters provided with the process server 
include Web services, messaging services, and database 
connectivity services. 


Industry standard adapters to allow SAP and the old 
ERP/legacy systems to be initiators, participants, or 
recipients in a variety of business processes without change 
to the host applications. Adapters provided with the 
process server include SAP, Web services, messaging 
services, standard file, and database connectivity services. 


¥ Service choreography facilities to allow Spotlight to plug 
and play, binding application snippets and services to 
provide an appropriate process to address business needs. 


Human workflow services included in all choreographed 
process flows — hand-offs to humans, alerts, notifications, 
and task assignments. 


¥ Graphical depiction of the business process flows operating 
in the runtime environment, allowing business involvement 
in what the technology is actually running. 


Compliance with open standards (service standards bodies 
including OASIS, W3C, WSI, and IETF). 
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Graphical representation, mediation, and transformation 


between an application-specific view of Spotlight’s business 
and the overall Spotlight model. 


This process server technology provides a simple architecture, 
allowing Spotlight to focus on the tasks (services) that must be 
done to improve its business and also to choreograph the 
process flows from these tasks. 


Lessons Learned and Best Practices 


The 20-month timeline for implementing change was certainly a 
whirlwind for Spotlight. Based on its experience, it recommends 
the following: 


Bring in the experts. According to McDiarmid and Redwood, 


if you’re fundamentally going to change what you do in every 
way, shape, and form — and your're going to fast-track it — 
you need to bring in experts. Spotlight brought in KAZ as it 
overhauled its infrastructure and a separate group of 
consultants with SOA skills to help fast-track its ERP 
implementation. 


Know your business. You also need to have a clear 


understanding of what your business is and what the business 
processes are. Spotlight knew its business as well as the 
business processes it needed to accomplish. It was able to 
help fast-track its implementation because it had a good 
handle on its processes and requirements. 


Establish trust between IT and the business. The teams at 


Spotlight realized that they were in the project together. 
Rapid change can happen only if both sides of the house 
understand the plans, the complexity of the plans, and the 
benefits of the approach. In this way, the two groups can 
better communicate and build trust. 


Plan for a skill transfer. In Spotlight’s case, it knew that its 


current workforce couldn’t handle maintaining its existing 
systems and putting a new infrastructure in place. It was too 
much work, and the team didn’t necessarily have the skillset. 
However, the plan is to transition the work to the in-house 
staff. The Spotlight IT department knew upfront that 
consultants were coming in to work on the conversion, so 
there were no role issues. 
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Chapter 7 
Telecommunications 


In This Chapter 


Looking at Telenor Iris’s business initiative for SOA 
Understanding why telecommunications needs SOA 


Going over what’s next for Telenor Iris 


T°: telecommunications industry has changed dramatically 
from being a virtual monopoly to a highly competitive global 
market. Today, telecommunications companies provide a range of 
products and services to support local and long distance wire-line 
calling, wireless, TV, Internet, and a host of other network offerings. 
Because competition is fierce, telecommunications product and 
service providers are always looking to provide their customers 
with value added services as a way to differentiate their offerings. 
Speed to market, customer service, and delivering innovative 
products and services are all critical to success. 


In this chapter, we highlight Telenor Iris, a subsidiary of the global 
mobile communications provider, Telenor. Service oriented arch- 
itecture became the linchpin of the company’s strategy to deliver 
innovative products and services to customers with agility and 
flexibility. The company’s requirements for data quality are 
extremely high given its focus on data aggregation services for 
customers. Improving data quality and overall data management 
was an important motivator behind Telenor Iris’s decision to 
implement SOA. 


Telenor Iris 


It’s important to be quick and flexible when launching new products 
or services for customers — and that’s what Telenor, the seventh- 
largest wireless provider in the world (with 143 million subscribers), 
wanted to do when it created its new Iris division. Telenor Iris, a 
subsidiary of Telenor, is an innovation activity within the parent 
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company. Telenor had been growing rapidly the last few years, 
expanding through emerging markets, and had reached a certain 
maturity level in its home market. It was looking at new areas to 
expand and was interested in creating managed, ’Net-centric 
services in particular. 


The company saw an opportunity in offering managed services 
for organizations that want to take advantage of RFID (radio 
frequency identification) and other sensor technologies in their 
supply chain for inventory control. RFID is a technology that uses 
tiny computer chips to track items at a distance, by emitting 
radio waves. An example of this is tracking containers from one 
location to another. According to Magus Bakken, General Manager 
of Telenor Iris, what appeals to customers is the ability to offer an 
automated collection service without having to install a software 
stack at the customer site. To provide a managed service, the 
team needed to have a framework to offer a variety of services to 
different companies. Two critical requirements included the 
ability to track huge amounts of information and also to integrate 
with legacy systems. 


The Enterprise Service Bus 


Iris began its SOA journey in 2007. It knew that to offer managed 
services to its customers, it needed to be extremely flexible 
because each customer would have slightly different requirements. 
For example, the team needed to be able to gather information 
from a wide variety of sensors and RFID readers. And at the back 
end, the team would have to integrate into a customer’s ERP 
system or other applications that were in use. SOA provided the 
right framework for this. 


Telenor Iris needs to be able to track items as diverse as lettuce 
and auto parts. For example, one customer might be interested in 
tracking produce. Telenor Iris collects data from many different 
locations — from the production plant, the trucks, the distribution 
center, and then out to the retailer. It then pushes the data from its 
location into a third-party application that allows the customer 

to view where the produce is, when it left the plant, and when it 
arrived into the retailer’s store. Temperature information is tied 
into this so that the customer knows that the produce is being 
kept fresh. 


A key element in the solution is the enterprise service bus (ESB). 
When information is transmitted from the RFID devices, it goes to 
a server, where it is transformed and placed in a queue to be sent 
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to the ESB. The ESB is the backbone of the service. It functions as 
a hub, directing the messages that come from the sensors. The IT 
system needs to have some basic information about a message to 
know how it should be treated. The ESB collects this information. 
It looks up where the messages came from and who owns the 
message. Then, after this information is known, the services that 
the message is subscribed to are called in a specific order, and 
information is routed to the appropriate place. 


The team developed a number of services to support the offering. 
These include a message tracking service and a sensor store 
service, which stores all the messages that are gathered for logging 
and control purposes. There is also a billing service. On the back 
end, the company can integrate to its customer’s ERP systems or 
other applications using a series of adapters. 


These services are all reusable, which is very important to 
Telenor Iris. As a managed service, it needs to be able to scale the 
business efficiently. Reusable services enable Telenor to capture 
information from many different types of RFID readers. This 
allows the company to sell to a much more diverse market than if 
it provided integration with only specific types of RFID readers 
and certain ERP systems. For Telenor Iris, reusability means 
flexibility, and flexibility leads to growth. 


Data quality is also an issue for Telenor Iris because the main 
service it offers is data aggregation. It needs to ensure that the 
right data goes to the right customer — for example, the right 
temperature or weight data. Also, sometimes the RFID readers 
provide data that isn’t reasonable — like a weight that is ten 
times what it should be. The data needs to be reliable, and it 
needs to be secure. 


Scaling the Service 


RFID generates quite a lot of traffic, and the service needs to be 
able to handle this high traffic load — hundreds of tags per 
second. The architecture has to handle the traffic in a reliable 
way. How is the team dealing with this? 


Here’s how Juan Carlos Lopez Calvet, technology manager at Iris, 
sees it. Because basically all the data that Telenor Iris gathers is 
message-based and asynchronous, it needs to take care of these 
messages at various layers. This means that Iris has to be able to 
store the messages in case the network link goes down but then 
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resend the messages when the link comes up and also route the 
messages properly. To do this, the company uses message 
queues and filters at different layers: 


The first filtering step is at the reader layer. An edge server, 
which gets the messages from the readers, provides some 
aggregation, depending on the customer’s business logic. 
For example, the service reads all the tagged contents ina 
storage room but informs the application only about items 
that have been removed. 


1” The second layer provides the message queue that enables 
Iris to persist the messages in case of network failure. This 
means that the message is not lost if the network goes 
down. The plan is to have virtual copies of these queues 
that share the load of incoming messages. Each queue 
stores the messages and attempts to send them to the 
incoming service on the ESB. 


The final layer is the ESB that helps to dynamically route the 
messages and to provide load balancing at the services level. 


What’s Next? 


In addition to scaling out the service, Iris plans to allow 
companies to share information on specific items by using a 
standard interface; this will increase the visibility within the 
supply chain. In other words, the service will be extended so that 
other supply chain partners can view the status of the items 
being tracked. In order to do this, the team plans to implement 
the Electronic Product Code (EPC) Information Service, which 
allows them to publish and subscribe EPC data by using a 
standard interface defined by an organization called EPC Global. 
The EPC Information Service is a specification for a standard 
interface for accessing EPC-related information. The standard 
interface allows trading partners to use the same function for 
querying data across the supply chain. 
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Chapter 8 


Energy and Utilities 


In This Chapter 


Looking at Delaware Electric’s business initiative for SOA 
Understanding why energy and utility companies need SOA 


Recognizing lessons learned about the importance of business process 


Frees and utility companies are on the hot seat these days. In 
the old days, they were responsible for literally keeping the 
lights on. With increases in energy costs and increased emphasis 
on finding cleaner and renewable energy sources, utilities now 
have a much tougher task. They have to provide good service to 
a broad range of businesses and individuals at a reasonable cost. 
And it isn’t easy. These companies also have to get creative in 
complicated times. For example, utilities have to find ways to 
partner with businesses and individuals to conserve energy. 
Energy providers also have to be able to provide good feedback 
so the energy consumers understand how they can adjust their 
energy consumption behavior to conserve energy and save on 
energy costs. Consumers need to understand how much energy 
they use at different times of day and different seasons. 


What does this have to do with a service oriented architecture, 
you might ask? The following case study on Delaware Electric is a 
great example of how a utility used SOA to help break down infor- 
mation silos, improve business processes across the organization, 
and develop a technology framework to support future business 
requirements. The utility’s technology innovations help to build 
partnerships that result in energy conservation. 


Delaware Electric 


Delaware Electric is an electric cooperative that serves 80,000 
customers. Its entire staff of 140 employees includes an IT staff of 
only 4 people. Of the more than 900 electric cooperatives in the 
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United States, Delaware Electric is one of the fastest growing — 
great news, of course, but its success hasn’t always been easy. 


Problem #1 occurred when the utility was deregulated. At that 
time, the state utility commission put a freeze on electric rates for 
five years, meaning that the cost of a kilowatt-hour was fixed — 
Delaware Electric couldn’t raise the price. And in times where the 
cost of energy continues to rise, Delaware Electric had to do 
something clever to keep ahead of things. Now, electricity is a 
commodity like any other, and an electric cooperative’s success 
depends on delivering that commodity in a fashion that impresses 
its customers. Energy costs, on the other hand, are rising steadily, 
which means that Delaware Electric had to find ways to cut its 
own costs without compromising service. 


The onus of Delaware Electric’s business predicament (and financial 
success) fell upon everyone, including its Chief Financial Officer, 
Gary Cripps. He was first and foremost a businessman who viewed 
his primary responsibility as “keeping the lights on” — not only 
metaphorically, as in keeping Delaware Electric solvent, but 
literally for all 80,000 Delaware Electric customers. He was also 
responsible for Delaware Electric’s small IT organization and 
brought a business-focused perspective to the IT environment. 


Looking to IT to Solve 
Business Problems 


Looking for ways to optimize, economize, and deliver better service, 
Cripps closely examined the various IT systems already in use at 
Delaware Electric. He found a lot of critical systems that didn’t 
talk to each other. He looked around for some sort of packaged 
software that would solve the problems efficiently but found 
none. “We simply couldn’t find a software package that would 
handle the diversity of requirements that would provide inte- 
gration for all of our business needs and would provide real-time 
services,” is how he put it. 


In addition, Cripps wanted each department to be able to use the 
software that best fit that department’s business goals — based 
on the best software available — and he understood that all these 
individual systems needed to be brought together if Delaware 
Electric was going to achieve the efficiencies required for a viable 
business. 
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Delaware Electric decided that SOA would help break down the 
barriers between various systems, allow it to leverage the critical 
assets it already had, and provide a framework for future require- 
ments. As Cripps said, “The primary objective was to integrate 
our processes across the enterprise in order to become more 
member-centric.” 


That undertaking ended up being no small feat. Delaware Electric 
had many packaged applications that were critical to running the 
utility. Although each of these applications performed a valuable 
function, each was isolated from the next. Therefore, for example, 
employees had no way to connect information about a service 
outage with information about which customers were affected. 
They had an interactive voice response system, but it couldn’t 
communicate with the system that tracked outages. 


When applications can’t talk to each other, people have to fill the 
gaps. Employees created manual processes to move between the 
various business functions separated by the individual appli- 
cations. Faced with the necessity of cutting cost, these complex 
processes were a luxury Delaware Electric could no longer afford. 
Ironically, even if Delaware Electric had funds to add people to 
solve the gaps in business process, manual processes are 
inefficient and prone to error and would likely have had a 
negative effect on customer service. 


Cripps’s team members realized that they needed infrastructure 
software focused on integrating business processes across isolated 
applications. Specifically, they wanted to integrate business 
processes within that part of the company responsible for 
everything that happens in the field — that is, on customers’ 
premises. For example, they wanted to be able to compare their 
customer information system — including the ability to load 
mapping data from a geographic information system (GIS) — with 
information coming from the Distribution Management (Outage) 
System. Delaware Electric needed to be able to compare this 
information in real time, especially during serious outages that 
could affect a huge number of consumers. 


Getting Some SOA Help 


The management at Delaware Electric understood that they didn’t 
have the expertise or the staff to undertake this plan. Instead, they 
worked with three consultants to develop a strategic plan. Working 
together, the team developed a customer-focused plan that 
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identified key business processes. They then mapped the process 
plan to the various applications across the organization. 


To manage power outages, they had to link the customer 
database and the field engineering database, and they needed a 
way to connect these applications with the company’s interactive 
voice response system. All these systems had to be integrated 
with all the processes throughout the company. Delaware 
Electric’s management understood that they could benefit greatly 
from changing the focus of their IT systems to support efficient 
customer service, but that meant shifting the focus away from the 
billing system that had been the primary focus. 


The consultants recommended using an enterprise service bus 
(ESB) as a way to link packaged applications to each other. In this 
first phase, Delaware Electric used Web service interfaces to hook 
its various packaged applications into the ESB. This phase required 
both the subject-matter experts within Delaware Electric and the 
consultants working with the package software vendors to connect 
these applications into the ESB. As a result, Delaware Electric’s 
PR department can say, “We can now provide more services to 
our customers.” 


Delaware Electric completed Phase One of its journey. Its employees 
have integrated the outage management system with GIS and the 
field management system. They are currently integrating the 
customer information systems into the ESB. They are also in 

the process of installing automated meter-reading equipment and 
connecting that equipment into the ESB. These additional projects 
will require an understanding and mapping of business processes. 


Realizing the Importance 
of Business Process 


After Delaware Electric worked through its initial starting point 
with SOA, management decided to take SOA to the next level. The 
focus was automating business process in the field so that the 
systems from accounting to engineering applications to materials 
management could communicate with each other from a process 
standpoint. 


Cripps is very proud that Delaware Electric has been able to reduce 
the mapping backlog significantly. He explained, “We used to have 
2,100 work locations in the backlog. This required follow-up and 
field visits, which obviously has had a significant reduction in 
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hours spent by employees. With the change based on business 
process, a lot of work is done automatically. We focus on not 
writing the code because we are a true believer in understanding 
the business process.” 


Rather than just jumping into business process, Cripps’s team 
members took a step back. They realized that more than half the 
time required to get a project done was determining the right 
business process. In contrast, writing adapters took only 20 percent 
of the time. If a project would cost Delaware Electric $200,000, as 
much as 80 percent of that work related to getting the business 
process right. Delaware Electric determined that it made the most 
sense to have the IT team work directly with the business to 
determine what the business process is today and how it could be 
streamlined. Cripps said, “We understand that business process is 
profitable from a technical view. If our organization can determine 
how we want to innovate with process, we can bring in coders to 
finish the job.” 


Cripps has an interesting perspective with Delaware Electric’s 
journey to SOA. He explained, “I am a CFO first. It is a lot less 
expensive for us to optimize technology within a SOA environment 
than to pay expensive consultants to start from scratch each time 
we need to innovate and streamline processes.” 


Delaware Electric has ambitious plans for using SOA for innovation 
in the energy field. It wants to start using SOA to affect the energy- 
metering side of the business. As Delaware Electric completes its 
goal of putting automatic meter readers in all homes and businesses 
(80 percent complete), it can start using its data to take action. 
Cripps said, “There are times when I am buying a kilowatt hour for 
a penny and other times when it costs a dollar. We feel we can use 
SOA to help inform customers, real-time, that if you curtail your 
energy use now, or at a specific time, you can reduce your payment 
to us and we save money. I can contact customers through e-mail, 
text messaging, and, in the future, through their meter, to encourage 
them to partner with us on energy savings. Successfully managing 
real-time business events and leveraging our data sources can save 
our consumers and the utility almost $300,000 per month because 
of conservation and energy management. That’s big money!” 


Reflecting on how Delaware Electric’s SOA plan will benefit its 
customers, Cripps says this: 


Imagine that you are an individual who is in the process of 
adding an addition to your home. You need the electric 
company to tell your contractor where the electric hookup is on 
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your property and you need them to come out and work with 
the contractor to plan for the extension of power to the addition. 
With the new process and the enterprise service bus in place, 
you will be able to call Delaware Electric and have the clerk at 
the call center go into the application, look up your house, 
view where the hookup is, and tell you when the technician is 
scheduled to arrive. The call center clerk will not have to 
know how each of these systems works; he or she will simply 
be able to fluidly move from one function to another. The 
customer gets the information they need in a timely manner, 
and everyone is happy. 


With the focus on customer service, the folks at Delaware Electric 
believe that SOA will help its customers minimize energy costs. 
With the new SOA environment, customers can go to the Web and 
view their own energy consumption. Customers can see when 
peak energy times occur and thus schedule major energy use 
(such as a printing production run) for a time when energy usage 
is low, thereby saving money. Cripps continues: 


Ifa consumer has an electrical problem, I want my call center 
representative to be able to determine whether there is a 
problem with our system or a problem within the customer's 
home. If we have to dispatch an expensive line-truck only to 
discover that the problem is unrelated, everyone loses. On the 
other hand, if the call center representative can verify energy is 
flowing at the meter, we can inform the customer that they 
should call their own electrician. This could save the customer 
many hours waiting time only to be told by the technician it’s 
not the utility’s responsibility. When the call center is able to 
intervene in this way, the utility saves money by not sending out 
expensive service resources, and the consumer has the right 
person fixing the right problem at the right time. 


Now, that’s progress! 


Delaware Electric’s business problems were ripe for SOA, but it 
took astute management to recognize the need and opportunity. 
The acute problem of needing to cut costs while at the same time 
delivering better service led Cripps’s team to take a close look at 
the entire company. Understanding that many of the problems 
stemmed from the fact that the applications in the various parts of 
the company “couldn’t talk to each other” — and that if they could, 
the whole company would benefit — was key to selecting SOA. In 
some ways, Delaware Electric was lucky — it recognized the value 
of innovation and knew it didn’t have the resources to tackle it on 
its own. Buy-in from senior management is critical to SOA success. 
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Chapter 9 


Top SOA Quick Starts: Entry 
Points for Starting the 
SOA Journey 


In This Chapter 


Charting your business structure 

Adopting best practices with industry frameworks 
Speeding adoption of standards with industry frameworks 
Getting your team ready for the journey 


Making sure you don’t go it alone 


f you made your way through the case studies in the previous 

seven chapters, then you have seen how varied the challenges 
and solutions can be across different companies. Hopefully, you 
have been able to recognize a little bit of your own company in 
the stories we have presented about these SOA pioneers. Now it’s 
time to plan your journey. We have two strong caveats about 
what you shouldn't do: 


¥ Don’t try to boil the ocean. Don’t attempt to do everything 
at once. Initially, prove your success with SOA by starting 
with a project that is small, achievable in a short time, and 
will have a significant impact — then build incrementally. 


If you’re business management, don’t turn SOA over to the 
IT organization and wash your hands of it. If you are IT 
management, partner with business management. For SOA 
to be effective, it must be done from the top down. In other 
words, if you really want your SOA plan to succeed, business 
management and IT must work together. 
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So, how should you approach SOA? You need a SOA plan that 
combines a business perspective, a technology road map, 

and an organizational initiative. Instead of giving you a deep, 
philosophical discussion on these (and other) matters, however, 
here are some practical guidelines for getting started with SOA. 


Mapping Vour Organization’s 
Business Structure 


One of the biggest differences between planning for SOA and 
planning for any other technology initiative is that SOA planning 
forces you to think differently about your company, industry, and 
ability to innovate as well as the value of technology. 


What does your company do, anyway? Are you in the retail 
business? If so, do you manufacture the products you sell, or 

do you sell products from a variety of manufacturers? Are you 

a financial services company? If so, do you put forth one type 

of offering or many? Do you have business partners who are 
important to your business? Are you a distribution company? 

If so, what makes you different from other companies in your 
market? And what does it actually mean to be “different” in your 
market? Finally, how should an innovative company act tomorrow 
and in ten years? Can you anticipate how you will have to 
compete two months from now or two years from now? Are you 
able to leverage your unique intellectual property to leapfrog the 
competition? 


Start your journey by stepping back and figuring out what your 
company is really about and how what you are translates into 

the core business services that define your business. Most 
businesses have key factors that have made them successful over 
time. SOA structure requires you to think from the perspective of 
reuse. In order to think from that perspective, you need to figure 
out a way you can structure the business as a set of services. 
Think about how to define your own business as a set of discrete 
services. 


The good news is that you probably don’t have to start from 
scratch. Many vendors have done a lot of work to create maps or 
frameworks particular to specific kinds of companies, and those 
vendors are happy to help you get started. Leveraging industry 
best practices and standards through the use of industry 
frameworks can help you to speed implementation and to drive 
successful outcomes. Industry frameworks can help in two 
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important areas: 1) understanding and incorporating industry 
best practices and 2) adopting industry standards and 
compliance requirements. You probably don’t want to try 

to tackle SOA without help. 


Using Industry Frameworks to Adopt 
Industry Best Practices 


Once you begin to map your organization’s business structure, 
you should also look for existing industry frameworks that have 
been created based on the best practices of other companies. 
There are thousands of SOA implementations in progress at 
companies and you can learn from their experiences. Some of 
these companies will follow business processes that are similar 
to those followed at your organization. We understand you 
have some unique workflows and business processes that are 
important to your differentiation. But there are also many 
processes that can be identified that will be nearly identical 
across different organizations in your industry. 


Look for pre-integrated software components and pre-built 
reusable services that you can begin using right away. An 
industry framework can also be used to help you create a SOA 
roadmap to ensure a successful journey. You can expect a faster 
and more accurate SOA implementation because you are, in 
effect, learning from the mistakes of others. 


Chances are that your SOA vendor can help you get started with 
a framework designed for companies like yours. Consultants, 
system integrators, and software vendors who have worked 
with hundreds of companies just like those presented in the 
previous seven chapters have codified their best practices into 
models or frameworks that you can leverage. Compare one of 
these frameworks to your own company and then modify the 
particulars that make your company different from the model. 
Voila! You now have a view of your company as a set of business 
services. This framework helps you figure out where to start. 
When developing a framework specific to your company, include 
the following steps: 


Discover and gather business requirements. 


Research your current set of assets so you know what you 
have today. 
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Simulate and optimize the business process of your 
company. 


Determine what you need to measure in order to figure out 
how well your business is performing. 


Adopting Standards Faster with 
Industry Frameworks 


Hopefully, we have convinced you that using industry frameworks 
will help keep you from reinventing the wheel as you begin your 
SOA implementation. Now, we’d like you to think about all those 
industry standards you need to pay attention to — ACORD for the 
Insurance industry, SWIFT for the financial services industry, 
ARTS for the Retail industry, and RosettaNet for commerce across 
industries. Vendors who offer an industry map or framework 
should ensure that these codified standards are supported. 
Working with an industry framework becomes a very pragmatic 
approach where standards are concerned. You can adopt 
standards faster while lowering the cost and overall risk of your 
implementation because a lot of the heavy lifting has been done 
for you. 


Picking Vour Initial SOA Targets to 
Gain Experience and Demonstrate 
Success 


If you try to move your entire company to SOA overnight, you'll 
likely end up living your own worst nightmare. Instead, start by 
reviewing the business services map to identify your first target. 
Select a specific area where you can leverage existing software 
assets, turn them into services, and create a plan that demon- 
strates the value of the flexibility you’ll gain from SOA. You don’t 
need to start with something huge. Rather, you should start with 
something that is important to management so the effort will be 
noticed. Remember, you’re proving that SOA works in your 
organization and has real value. 


For example, we know an insurance company that chose its 
Claims Processing department for its first SOA implementation. It 
turned the method of processing a claim into a business service 
called (tah-dah!) Claims Processing. By making it easy to change 


These materials are the copyright of Wiley Publishing, Inc. and any 
dissemination, distribution, or unauthorized use is strictly prohibited. 


59 


Chapter 9: Top SOA Quick Starts 


provider information, the company was able to add new claims 
providers in a few weeks rather than the 24 months it took 
previously. This speed allowed the company to add new partners 
quickly and increase revenue. In addition, the company was able 
to offer this flexible and rapid Claims Processing service to other 
companies, providing a new source of revenue for the company. 


We recommend that you pick a high-profile area where you can 
see results quickly. Demonstrating the benefits of SOA can make 
business change much less painful. You might have many good 
choices about where to start. One company might need to create 
a portal or a specialized Web site that brings key business 
services together to meet an immediate business objective. The 
portal view can help create an entirely different user experience 
within an organization. Another company may need to provide a 
single view of customer data so that various departments, 
subsidiaries, and business partners can find creative ways to 
grow revenue by focusing on customer opportunities to up-sell 
and cross-sell. Other companies may choose to focus on getting 
the necessary architectural components in place to support their 
movement to SOA. Still others may look at the manageability of 
various processes. Other companies may focus on the security 
aspects of SOA, while others will look at issues around 
governance. 


We could list hundreds of different options — all perfectly 
appropriate for a particular company or concern — but you, and 
you alone, know best what will have the greatest impact for your 
organization. Figure out what will get the biggest bang for your 
buck and go for it. 


Why you shouldn't wait 


If you are a company CEO or high-level 
manager, you may be thinking this SOA 
stuff sounds complicated — and very 
new. You may think that maybe you'd 
be better off waiting a few years until 
the vendors have all the angles figured 
out. Our advice: Don’t wait. Because 
SOA is as much a philosophy of mak- 
ing technology work for your business 
as anything else, it is a fundamental 
shift in the way you work. You'll need 


time to find how to work across depart- 
ments and turn your software assets 
into reusable components. 


A singular advantage of SOA is that 
companies can get started using itin an 
incremental manner, identifying and 
building SOA components that are in 
support of the core business with a 
mind to building a SOA architecture in 
due time. 
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Preparing Vour Organization for SOA 


No matter where you start, all roads lead to the people. SOA is 
about how people across organizations work together to change 
the way they think about the intersection of business and 
technology. In this regard, the organizational issues are much 
more important than any single technology issue. Often, 
departments within organizations work in isolation, and corporate 
structures have been designed to emphasize departmental 
objectives rather than cross-departmental cooperation. For SOA 
to succeed, organizations need a new way to think about the value 
of technology, one driven by a corporate-wide effort to approach 
technology differently. 


In order to kick-start such a new approach, we recommend 
establishing working groups that span departments. Separating 
work by different parts of the organization isn’t going to fly. 
Information can’t be owned by one department: Information is a 
corporate asset, as are business services. Business services must 
be valuable across many different departments. We recommend 
that top management establish SOA as a corporate mandate and 
set up an organizational structure that encourages and fosters 
its development. Establishing recognition programs that reward 
cooperation between the IT and the business departments is 

a good starting point. If your company isn’t at that stage, find 
high-profile departmental executives who can set an example. 
You'll need to approach different areas from different points 

of view. 


IT developers need a different approach 


Most IT developers are used to writing code that lives within its 
own enclosed world. When an organization begins the movement 
to SOA, developers need to start writing software based on the 
assumption that the software will be used in many different 
circumstances. Developers who come from the old school of 
doing things don’t necessarily see this as an intuitive approach. 
Part of preparing the development organization is helping them 
understand how the business might use the components they’ll 
be asked to build. Developers should be teamed with business 
professionals across the organization to help developers change 
to a more global perspective. It’s also important to allow time for 
constituents and stakeholders to arrive at a mutual 
understanding of project goals. 
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Business managers need to look beyond 
their own departments 


Business managers tend to worry about their own department’s 
goals and objectives as well as the metrics that they’re judged on. 
SOA involves thinking creatively about business processes and 
business measurements as they affect the enterprise as a whole. 
To appropriately identify key business processes, you need 
cooperation between departments and divisions. 


Finding Out Why Business Partners 
Are Part of the SOA Success Story 


In a highly competitive business world, no company is safe 
without partners. SOA can play an important part in making 
partnerships innovative. Any company that has a SOA strategy 
needs to implement its strategic plan in conjunction with 

its business partners. Partners may need to be educated 

on the value of the strategy and how it will help them take 
advantage of the combined strengths that partnerships can 
create. Some forward-thinking partners may have already 
started their SOA journeys. 


Getting Help with SOA 


SOA is a journey, not a one-time project that a single department 
implements to get a quick hit or quick success. It’s a corporate- 
wide process to leverage technology in a way that reflects key 
business processes, enabling business to change when needed 
without being constrained by technology. Therefore, don’t 
approach SOA in isolation. Find yourself some help. Look for 
technology suppliers that have created successful SOA 
implementations for companies like yours. Admittedly, you 
probably won’t be able to find a single vendor that can provide 
you with everything you need. Still, you should actively look for 
companies that can offer you an easy-to-implement package 
based on established standards that you can then add pieces to 
(or subtract pieces from) as your implementation matures. 
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Look for models of SOA success. What can you glean from 
companies that have already started on their SOA journeys? 
What would they do differently? What worked well for them? 
How have they managed to get their people to work together 
toward a common goal? 


Setting Off to the Races 


We hope we’ve given you enough to whet your appetite for 

SOA. And we hope that understanding more about the actual 
experiences of companies that have already put SOA into action 
has provided inspiration for your journey. We believe that a 
service oriented architecture will be critical for any business that 
relies on technology to run the business. The world is changing 
rapidly, and SOA helps an organization keep pace. SOA can help 
“future-proof” a company — making it ready and able to change 
when change inevitably comes. 
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